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METHOD OF AUTOMATIC UPLOADING OF THE REQUIREMENTS OF 
UML MODELS AND OF THEIR UPDATING 

The present invention pertains to a method of automatic uploading of the 
5 requirements of UML models created by a modeling tool, and of their updating. 

When modeling a project, whatever it may be, use is currently made, in a 
preferential manner, of the UML language, implemented in a modeling tool, such as 
"RHAPSODY" from the company I-LOGIX. The modeling requires the 
consideration of requirements, and for this purpose, a requirements management tool 
10 such as "DOORS" from the company TELELOGIC is made available. However, 
there does not exist any means making it possible to ensure the traceability of the 
information of the model so as to keep the requirements management tool informed 
thereof 

The present invention is aimed at a method of automatic uploading of the 
15 requirements of UML models to a requirements management tool so as to allow their 
updating, doing so without limitation on the placement of requirements and their 
number. 

The method in accordance with the invention is characterized in that the 
requirements are created dxiring the creation of the elements of the UML model, that 
20 once the model has been stabilized, the requirements entered into the model are 
exported to the requirements management tool and there is created automatically a 
navigation module containing all the UML objects pointed at by at least one 
requirement and a requirements module of level n. Advantageously, the requirements 
module of level n is linked to another upstream requirements module of level n+1 
25 defined previously. 

The present invention will be better understood on reading the detailed 
description of an embodiment, taken by way of nonlimiting example and illustrated 
by the appended drawing, in which: 

- Figure 1 is a simpUfied block diagram of an exemplary 
30 implementation of the method of the invention. 
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. Figure 2 is a chart illustrating the first importation of a UML model 
into a requirements manager, according to the method of the 
invention, 

- Figure 3 is a chart illustrating a new importation, imder the same 
6 conditions (import level 1) as in Figure 2, 

- Figure 4 is a chart illustrating a new importation of a UML model, 
but at a different level (level 2) from that of Figure 3, 

- Figure 5 is a chart illustrating the automatic placing of traceability 
links from the module to other DOORS modules according to the 

1 0 method of the invention, 

- Figure 6 is a chart in four steps, illustratmg the successive operations 
intervening during a new iteration of importing of a UML model into 
a requirements manager, according to the method of the invention, 
and 

15 . Figures 7 and 8 are charts showing two states of a Requirements 

module of the requirements manager, respectively before and after a 
new importation, according to the method of the invention. 
Represented in Figure 1 are the main elements of the architecture of the 
system implementing the mvention. These elements are: a UML modeler (1), which 
20 is, preferably, the "RHAPSODY" tool, a tool (2) for managing UML Requirements, 
which is, in the present case, the "DOORS" tool, a workshop of utilities (3), which is 
here "DOORS Custom" from the company THALES AVIONICS and a universal 
inter-tools connection connector (4) "PAPEETE" (fonning the subject of a patent 
application from the company THALES). The importation of UML models into the 
25 DOORS tool from the RHAPSODY tool is done in the following manner. 

During the first importation of a UML model from RHAPSODY to DOORS (see 
Figxire 2), there is creation of two modules in DOORS: 

- A module (5) of UML DOORS Requirements corresponding to the 
specification level (level 1 for the example represented). This DOORS 
30 module contains the set of UML^DOORS Requirements which represent the 

stereotyped UML Requirements with the specification level chosen during 
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the importation. This module 5 here contains the level 1 requirements of the 
model. These requirements are, for this example: HLR_01, LLR_01 and 
HLR_03. 

- A UML navigation module (Surrogate UML Module) (6): this DOORS 
5 module contains a representation of the set of UML elements of the model 

created in RHAPSODY. This representation is in the form of reference to the 
UML elements. This module has as objective to allow navigation between 
RHAPSODY and DOORS (as set out in the "DOORS Custom User Guide" 
manual). 

10 The following importations of the same UML model can be of two different 
types. Either, as represented in the example of Figure 3, it involves the same 
specification level as previously (level 1 in this instance). In this case, at one and the 
same time the UML_DOORS Requirements Module and the UML navigation 
Module are updated as a function of the modifications made to the UML model. Or, 

15 as represented in Figure 4, they pertain to a different specification level (level 2 in 
this instance, involving the requirements HLR_02 and LLR_02). In this case, there is 
creation of a UML_DOORS Requirements module corresponding to the specification 
level selected (level 2) during the importation and updating of the UML navigation 
Module as a function of the modifications made to the model. 

20 The links between a UML_DOORS Requirement and its representation in the 
UML navigation Module are created automatically during the importation of the 
UML model imder DOORS. These links allow navigation between the two tools 
RHAPSODY and DOORS. 

The creation of links to other DOORS requirements modules is carried out in the 

25 following manner. After having performed an importation of a RHAPSODY model 
into DOORS, it is possible to automatically create the links between Requirements of 
the module created automatically and Requirements of another DOORS module or 
those of another module created automatically previously. This automatic creation of 
links is performed with the DOORS TREK utility "Create links by key . . .". Thus, as 

30 represented in Figure 5, during the importation of the specification level X, 
traceability links are created between the Requirements module of level X and, on 
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the one hand, the requirements module of level X-1, and on the other hand a module 
of quite another requirements specification level (SSS in this case) . 

The management of the modifications made to the requirements relating to the 
UML model is carried out in the following manner. 

5 The management of the modifications of the requirements implies the capacity to 
navigate between the RHAPSODY tool and the DOORS tool. Specifically, it is 
necessary to be capable of rapidly analyzing the impact of modifications of the 
upstream requirements on the UML model so as to apply the appropriate 
modifications to the elements implicated by this impact and conversely, 

1 0 To carry out the modification of UML_DOORS Requirements, it is not necessary 
to modify under DOORS the attributes of the UML_DOORS Requirements specified 
m the UML Requirements (as explained in the Guide to UML requirements 
modeling). These modifications must be performed only in the UML model imder 
RHAPSODY. 

15 Subsequent to a modification of DOORS Requirements, for each UML-DOORS 
Requirement which refmes it (as explained in the DOORS Guide) it is necessary to: 

1. navigate, with the aid of the DOORS/RHAPSODY navigation tool, to the 
associated UML Requirement, 

2. analyze the impact on the modeling of the modification to be performed, 
20 3. update the model 

4. update the UML Requirement in the model, 

5. import the modified model under DOORS, 

6. update the requirements management attributes under DOORS, 

Any model modification must be performed taking account of the UML 
25 Requirements which have a repercussion on the elements modified so as to maintain 
consistency between the UML Requirements and the UML model 

To do this, for each modified UML element it is necessary to consult the set of 
UML Requirements which have a repercussion thereon, so as to verify that these 
requirements are always consistent with the modification performed on the element. 
30 To manage the changes to a model manifested by successive modifications, the 
mechanism of successive importations is firstly examined. The importation of a 
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UML model under DOORS is performed in several steps. These steps are invisible to 
the user, since they are performed in one go during importation. The main steps of 
this mechanism of successive importations have been illustrated in Figure 6. This 
figure comprises foiu- charts (referenced 1 to 4). 
5 In the initial state (1), we have, in DOORS, a UML_DOORS Requirements 
module linked to a UML navigation module (by navigation links), these modules 
generated automatically during an earlier importation are dubbed "former". 

When a request to import the UML model aimed at an updating of these two 
modules arrives, the following actions are engaged: 
10 - creation of two new modules (2): 

o a UML_DOORS Requirements Module containing the set of 
UML_DOORS Requirements corresponding to all the UML 
Requirements contained in the new UML model imported, 
o a UML navigation module representing the new UML model, 
15 - deletion of the former UML navigation module and of all the DOORS 
elements relating to it (3), 

- analysis of the updates to be performed between the two UML_DOORS 
Requirements Modules, 

- updating of the former UML DOORS Requirements Module (4), 
20 - deletion of the new UML_DOORS Requirements Module (4), 

- creation of the navigation links between the former UML_DOORS 
Requirements Module and the new UML navigation Module. 

The user must thereafter update the links for traceability with the upstream 
requirements. This step is not included in the importation of the UML model, but 
25 must be performed separately after each importation with the aid of the DOORS 
TREK utility "Create links by key . . .". 

The management of the changes can thereafter relate to the addition of 
requirements. If a UML Requirement is added to the model, there will be, during the 
following importation, for one and the same specification level, and one and the 
30 same UML model, creation of a new DOORS object in the corresponding UML 
navigation Module and in the corresponding UML navigation Module. 



6 



By way of simplified example, represented in Figure 7 is the state of the 
UML_DOORS Requirements Module before a new importation, and which 
comprises the Requirements EXI_01 to EXI_04 (in version vl). Represented in 
Figure 8 is the state of this Module after a new importation, EXI_02 being modified 
5 (coexisting versions vl and v2), and with a new Requirement EXI_05 (version v2). 

Likewise, if a UML Requirement aheady imported during a previous importation 
is deleted fi-om the model, dviring the following importation, the UML-DOORS 
Requirement corresponding to the UML Requirement, will not be deleted from the 
UML_DOORS Requirements Module, but will take the status "OBSOLETE" and all 
1 0 its DOORS links will be destroyed. 

If a UML Requirement aheady imported during a previous importation is 
modified in the model, there will be, during the following importation,: 

- creation of a new UML_DOORS Requirement corresponding to the UML 
Requirement 

15 - creation of a link between the former and the new UML^DOORS 
Requirement 

- transfer of the incoming and outgoing links from the former to the new 
UML_DOORS Requirement 

- updating of the version number on the new UML_DOORS Requirement with 
20 respect to the former. 

A journal of the modifications of requirements is thus obtained. 

In conclusion, the method of the invention makes it possible to upload 
automatically imder DOORS all the traceabihty information entered into the UML 
model. It automatically organizes under DOORS the whole process necessary for 
25 navigation between the two tools via the connector PAPEETE or an XML link (or 
equivalent). Finally it automatically organizes the whole updating of the modules 
during the various changes to the UML model. 



